Pull request overview

Updates the PolarisPrincipal attribute model from a raw Map<String, Object> to a type-safe AttributeMap, introducing shared typed keys and propagating the change through core auth/persistence logic, runtime service authentication, and extension authorizer tests.

Changes:

• Switch PolarisPrincipal to carry an AttributeMap and introduce PolarisPrincipalAttributes typed keys for principal entity / role-all / JWT attributes.
• Update runtime/service authentication and core resolver/auth preconditions to use typed attribute access.
• Migrate affected tests and extension integrations (OPA, Ranger, Kafka events) to the new attribute model and add coverage for defensive copying.

Reviewed changes

Copilot reviewed 38 out of 38 changed files in this pull request and generated 1 comment.

I guess I'm a bit late to this topic. I wonder is the intent supporting ABAC authz? do we have any pointer to the design doc that can better navigate me throughout prs?

IIUC, IMHO this PR, and the AttributeMap shape from #5139 it's built on, solves the wrong problem for principal attributes.

There are two different kinds of data on the principal today. The first kind: 3 values Polaris itself produces, where Polaris always knows the type ahead of time. That's the resolved PrincipalEntity, the PRINCIPAL_ROLE_ALL boolean, and an optional JWT string. The second kind: an open set of raw attributes copied from the identity provider, where Polaris does not control the keys or the types. AttributeMap treats both kinds the same way, and it doesn't serve either one well.Take the first kind, the 3 Polaris-owned values. PolarisPrincipal is @PolarisImmutable, with exactly one generated implementation, ImmutablePolarisPrincipal. Adding a named method for each of these 3 values costs one interface change plus a rebuild. Nothing else implements this interface, so nothing else needs to change. A named method gives a real compile-time guarantee: get the name wrong, and the build fails. AttributeKey doesn't give that guarantee. It's record AttributeKey(String key), so T plays no part in equals/hashCode. The javadoc says so directly: the type guarantee only holds "as long as callers never create two instances of AttributeKey having the same string key, but different types." That's a rule callers have to remember, not something the compiler checks. Dressing it up as a typed key makes it look safer than a plain Map<String, Object>, when it isn't.

Take the second kind, the raw attributes from the identity provider. L170 in DefaultAuthenticator does new AttributeKey<>(key), and value's static type there is Object, straight from identity.getAttributes(): Map<String, Object>. So every raw attribute gets typed as AttributeKey. That's exactly as safe as a plain string key, since there's no narrower type underneath it to protect.

I also don't think the raw attribute passthrough does anything today. Based on my search, nothing reads an attribute other than the 3 reserved ones off PolarisPrincipal.getAttributes(). So the raw attribute passthrough on PolarisPrincipal looks speculative right now, on top of not doing what it's meant to do.

What I'd suggest instead:

1.  Give PolarisPrincipal a named accessor for each of the 3 reserved values, instead of AttributeKey constants. @PolarisImmutable makes this cheap here.
2.  If a future caller genuinely needs the raw identity-provider attributes off PolarisPrincipal, carry them as a plain Map<String, Object> field, not AttributeKey entries. The typed key buys nothing when the value type is always Object.
3.  If neither set needs a shared string-keyed map, AttributeMap isn't needed for principal attributes at all. That also removes the "who owns this key prefix" question I'd otherwise raise about PRINCIPAL_ROLE_ALL_ATTRIBUTE_KEY, since there'd be no shared namespace left to collide in.

Let me know if missing anything here